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Summary This section describes the processing of priority levels, 


including context saving of inteérruptec tasks and the assignment 
of priority levels and logical resource numbers to tasks. This 
section also describes task communication and coordination as 


well as deferred processing. 
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INTRODUCTION 


A task can oe characterized as the execution of a sequence of 
instructions that has a starting point and an ending point, and 
performs some identifiable function. A task can initiate 
another task for execution or terminate itself by calling the 
task management commands or macrocalls. Multiple tasks can 
operate independently of and asynchronously to each other. 


Each application, system, or device criver task operates at an 
interrupt priority level, one of the 64 priority levels provided 
for each central processor by the hardware and firmware. 


CENTRAL PROCESSOR INTERRUPT PRIORITY LEVELS 


Number oF 
Levels 


Activity 
Indicators 


Interrupts 


All system tasks, device drivers, and application tasks are 
assigned interrupt priority levels that indicate the order of 
their execution. This order of execution may be changed due to 
timeslicing (see below) or because this is a multiprocessor 
system. 


Control of the central processor is given to the highest active 
interrupt level. However, in multiprocessor systems, a task at 
a lower priority may execute at the same time as a task of 
higher priority since each task is executing on a different 
central processor. 


Each central processor provides 64 potential interrupt priority 
jevels that are used by the hardware to order the processing of 
events. These levels are numbered from the highest priority 
(level 0) to the lowest priority (level 63). Levels 0 through 
5, 62, and 63 are reserved. The intervening levels (6 through 
61) are assigned to logical resources (that is, devices and 
tasks). . 


The determination of which priority level is to receive central 
processor time is based on a linear scan of the level activity 
indicators. The level activity indicators are maintained by the 
hardware in four contiguous dedicated memory locations in each 
central processor (see Figure 5-1). Each bit that is "on" 
denotes an active priority level; each bit that is "off" denotes 
an inactive level. 


Bits can be set "on" by software or by hardware events 
(interrupts). Most interrupting hardware devices are associated 
with priority levels during system configuration (by directives 
in the CLM_USER file). 
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Available 
Levels 


Interruot 
Processing 
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LOCATION BT 
(HEXADECIMAL)) O,1,2,3,¢,5.6 7,8 16,11 12,13, 14,15 
SIAN ONG A 8 18 9 Ny Ut NR 
0020 0920 < uid 
oozt rz [re a] | intenauer priority 
oo n n LEVEL NUMBER 
0022, 0122 | 2 = ” 
00230123 Las. 3 
NOTE: IF THE BIT CORRESPONDING TO AN INDIYIDUAL 
LEVEL 15 “ON”. THAT LEVEL IS ACTIVE, IF THE 
BIT IS “OFF”, THE LEVEL 1S SUSPENCED. 
86-023 


Figure 5-1. Format of Level Activity Indicators for Each 
Central Processor 


Tne three highest priority levels have dedicated assignments of 
special hardware/firmware functions such as incipient power 
failure, watchdog timer runout, and trao save area overflow. 
Priority level 3 is reserved as an inhibit level, level 4 is 
reserved for the timeslice clock, and level 5 is dedicated to 
the real-time clock. Succeeding levels are user-configurable as 
device levels. Following these are five levels reserved for 
system use. Except for levels 6Z and 63, the remaining levels 
can be used for application tasks. Level] 62 is reserved for 
system use. Level 63 is reserved for an always active software 
idle loop or, in multiprocessor systems, for the task 
dispatcher. 


When a given priority level is the highest active level, it 
receives all available central processcr time until it is 
interrupted by a higher priority level or until it relinquishes 
contro] by suspending itself (setting its level activity 
indicator off). If a priority level is interrupted by a higher 
priority level, its level activity indicator remains on and it 
will resume execution of the interrupted logical resource when 
it again becomes the highest priority level. 


Eacn time a priority level change occurs, the hardware/firmware 
saves the central processor context of the task running at the 
previously highest active level and restores the central 
processor context of the task running at the new highest active 
level. Interrupting a task, saving the context of a task, 
selecting and starting the highest priority level task. and 
restoring the context of a task are done without software 
involvement. 
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INTERRUPT SAVE AREA 


Task Context The context of a level (task) cam include the contents of the 


program counter, S-register, B-registers, I-register, 
K-registers, R-registers, M-registers, SIP registers, and CIP 
registers. The context is stored for each central processor in 
a block of memory known as an Interrupt Save Area (ISA). 


Interrupt The hardware/firmware context save/restore function finds the 
Vectors appropriate ISA through a pointer supplied in the interrupt 
vector for that level. The interrupt vectors are a set of 
contiguous memory locations containing an entry for each 
potentially active priority level and ordered by ascending 
priority level number. Figure 5-2 illustrates the order of the 
priority levels, their corresponding interrupt vectors, and the 
format of an ISA. 
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Figure 5-2. Order of Interrupt Vectors and Format of Interrupt 
Save Areas for Each Centra) Processor 
CZ03-02 5-5 


Task Execution 


TASK DISPATCHING 


The way in which a task receives central processor time depends 
on whether the system has one or more than one central 
processor. 


In a monoprocessor system, tasks are dispatched according to 
their priority level. The task at the highest priority level 
receives all available central processor time unti] it is 
interrupted by a task with a higher priority leve! or until it 
suspends itself. In a multiprocessor system, all tasks are 
dispatched from a general ready queue. The tasks are placed in 
the queue according to their priority level, with higher 
priority tasks at the top of the queue. The level at which a 
task executes stays the same, but the central processor in which 
it executes may vary. 


Monoprocessor Task Dispatching 


When a task in a monoprocessor system is at the highest active 
priority level, it receives all available central processor time 
until it is interrupted by a task at a higher priority level, 
until it relinquishes control by suspending itself, or until it 


. has contro) taken away from it due to timeslicing (see below). 


If a task is interruptea by a higher priority task, it wil? 
resume execution when it again becomes the task et the highest 
priority level. 


When more than one task is assigned the same oriority level, 2 
system software task at a higher level regulates in round-robin 
fashion the sharing of the level between tasks. Thus @ task 
does not block a level when the task is timesliced (refer to 
"Timeslicing" below) or when it is put in a waiting state after 
a request to wait, wait on list. request semaphore, or 
terminate, or after a system service macrocall that waits for a 
data transfer. Instead, the context of another task on the same 
Jevel will be linked to the level interrupt vector. 


Multiprocessor Task Dispatching 


In a multiprocessor system, the Executive maintains a queue of 
ready tasks ordered by priority level. This queve is called the 
general ready queue. The Executive dispatches the task at the 
top of the queue whenever a centra] processor becomes free to 
provide service. A disoatcher task runs at level 63 in each 
central processor and dispatches a task whenever it receives 
central processor time. The dispatcher tasks attempt to baiance 
the load so that high priority tasks are serviced before low 
priority tasks, and al? processors are used as fully as 
possible. 


an 
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TIMESLICING 
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The technique of timeslicing minimizes the ability of user 
tasks, that use large amounts of central processor time, to 
interfere with interactive users cf the system. Timeslicing 
uses a sampling technique to monitor all tasks at user levels. 
Configuration of timeslicinc is automatic. All user levels 
execute in a timesliced manner. Timeslicing options are 
ciscussed in the System Buiiding and Administration manual. 


Each running user task is monitorec by the scftware timeslicer 
logic. Fach user task is given a CPU time allocation (a time 
slice). the amount of which has been determ*ned by system 
software and is governed by tne arguments (default or explicit) 
associatec with the OSLICE bound unit. 


While a user task 78 running, timeslicing software is counting 
down the task's time slice allocation. 


When a task's time slice allocation becomes exhausted, the 
timeslice software, in general, will dequeue the sliced task and 
then decide whether to demote the sliced task one level or to 
place the sliced task behing all cther tasks ready to run on its 
current level. In either event, the system software will 
establish a new time slice allowance for the task. This 
allowance will be in effect when the task next runs. 


If @ task voluntarily waits (a synchronous 1/0 order, for 
example) while it still has time remaining on its current time 
slice, the reason for the wait is evaluated by system software. 
If tne wait is for a "tong" interval, thereby making CPU time 
available to competing tasks, the task wil] be promoted to (or 
stay assigned to) its native level when it next runs. If the 
wait is for a "short" interval, thereby limiting the CPU time 
available to other tasks, tne task will be given priority for 
completing its remaining slice when it next runs, but will then 
become @ candidate for possible demotion. 


The result is that all tasks are facilitated in using a given 
time slice, but those that voluntarily wait for "long" intervals 
become candidates for promotion, and those that wait for “short” 
intervals (or do not voluntarily wait et ali) become cancidates 
for demotion, 
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TRAP HANDLI 


Trap Classes 


User Traps 


ING 


The hardware provides a means by which certain events that occur 
during the execution of a task can be "trapped", with control 
being passed to software routines designed specifically to cover 
the condition causing the trap. Events such as the execution of 
a system monitor call, or the detection of a program errer, 
hardware error, arithmetic overflow, or uninstalled optional 
instruction cause traps (control transfers to designated 
software routines) to occur. 


Traps are divided into two classe (1) standard system traps, 
for wnich routines are supplied with the system. and (2) 
user-specific traps, for which users supply their own routines 
(handlers). 


An application program can designate which user-specific traps 
are to be handled by using the enable/disable user trap 
macrocalls (refer to the System Programmer's Guide - Volume II 
for details). If an enabled trap occurs in the user program, 
the Trap Manager transfers control to the connected trap handier 
for the condition causing the trap. A trap that is enabled is 
local to a task. Such a trap neither affects nor is affected by 
the handling of the same trap in another task, even witnin the 
same task group. 


Any trap that occurs when its handler is not enabled, or that 
does not have a handler to process it, causes the executing task 
to be aborted. 
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SYSTEM FEATURES AFFECTING TASK EXECUTION 


While the system does monitor resource use within a task group 
and among task groups. tasks and task groups must cooperate in 
their use of system resources to ensure smooth operation of the 
application. 


Priority Level Assignments 


Priority levels 6 through 61 are available for assignment to 
system, device driver, and application tasks. The system 
buiider establishes the priorities of system and driver tasks 
during configuration. (On the DPS 6/22, the Autoconfigurator 
establishes these priorities.) You assign the priorities of 
application tasks when you create task groups. Priority levels 
with low numeric values have higher priority than those with 
high numeric values. The procedures for establishing priorities 
are described below. 


Assigning Priority Levels to Devices and System Tasks 


The system builder specifies hardware interrupt priority levels 
through an argument of the DEVICE directive in the CLM_USER 
fite. (The Autoconfigurator is used on the DPS 6/22.) When-the 
system builder specifies a particular type of device, the 
appropriate Honeywell Bull written device driver is loaded as 
part of the system. The three priority levels following the 
last one assigned to a configured device are used by system 
tasks and cannot be assigned to application tasks. 


Reserved One example of priority level assignment is shown in Table 5-1. 

Levels Levels 0 through 5 are assigned by the system and are not 
available to any user. The operator terminal is assigned to 
level 8; however, the system builder can assign any appropriate 
level to the operator terminal through a DEVICE directive. (The 
operator terminal must be at a lower (numerically higner) level 
than the Communications Supervisor.) At initialization, the 
system bootstrap device is assigned to level 6. This assignment 
remains in effect unless changed by a DEVICE directive. 
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Peripheral 
Devices 


Assignable 
Levels 


Peripheral devices may be assigned to levels on both central 
Processors in @ multiprocessor system. This assignment is done 
automatically by the system. 


Table 5-1 indicates Input/Output (1/0} devices, and not device 
drivers, to stress that each peripheral device must have at 
least one level assigned to it. Except for communications 
devices, peripheral devices cannot share a level. If there are 
two printers, each must’be assigned a unique level even though 
there is only one copy of the associated I/O driver. 
Communications configurations require at least one nonshareable 
level dedicated to processing communications interrupts. This 
jevel must be higher than any level assigned to a communications 
device. 


Communications devices can share a level. For example, four 
teleprinters (TTYs) and one Visual Information Projection (VIP) 
terminal can be configured to share one level or to use up to 
five levels. The priorities in Table 5-1 provide maximum 
throughout because devices with high transfer rates are assigned 
higher priorities than devices with low transfer rates. 


Theoretically, the system builder could assign a level number as 
high as 58 to a device. In this case, levels 59 and 60 would be 
used by the system and only level 61 would be available for user 
task groups. In practice, however, the system builder would 
want to reserve more than one level for user task groups, 
especially for a system with a large number of devices. If 
priority levels 6 and 7 are assigned as shown in Table 5-1, the 
theoretical range of levels assignable through CLM COMM 
directives is 8 througn 58. For a device associated with a COMM 
directive, the range is 9 through 58. 2 
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Table 5-1. 


Physical 
Priority 
Level 


aaenno 


Base 
Priority 
Level 


N/A 
N/A 
N/A 
N/A 


N/A 


Power failure nandler 
Watchdog timer runout 
TSA overflow 

Inhibit interrupts 
Reserved 
Real-time clock 


System bootstrap 
device 


Communications 
Supervisor 


Operator terminal 


TTY device 
TTY device 
TTY device 


Sample Priority Level Assignments for Tasks and Devices 
{Sheet 1 of 2) 


Comments 


Levels 0 through 5 
are automatically 
assigned by the 
system, 


Set to level 6 at 
system initializa- 
tion but can be 

changed. 


Must be higher 
level than any 
communications 
device. 


Can be assigned 
any available 
level. 


Communications 
devices can share 
priority levels. 


Removable cartridge disk 
Fixed cartridge disk 


N/A 


Diskette 
Diskette 
Diskette 


Line printer 
Card reader 


The priority level 
for a pair of 
fixed/removable 
disks must be the 
same. 
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Physica? 
Priority 
Level 


Table 5-1. 


Bese 


Level 


17 N/A 
18 N/A 


63 N/A 


Priority 


Sample Priority Leve! Assignments for Tasks and Devices 
(Sheet 2 of Z) 


Conments 


Reserved by system The three levels 
Reserved by system following the last 
Reserved by system device-assigned 

jevel are used by 
the system, 


Task group A 
Task group B 


Task group n 


Reserved by system 
System idle loop or 
task dispatcher 


Always active. 
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Assigning Priority Levels to Application Tasks 


Base 
Priority 
Level 


Physical 
Level 


Recommended 
Priorities 


You assign priority levels to user task groups and tasks when 
you create or spawn them. The command to generate a task group 
contains an argument that specifies the base priority level for 
the task group. The base priority level is relative to the 
highest number priority level assigned to a configured device. 


When a task group is assigned a base priority level of zero, the 
Jead task of the group executes at the physical interrupt 
priority level tnat is three level numbers above the highest 
level number assigned to a configured device. When other tasks 
in the same task group are created or spawned, they are given 
Jevel numbers relative to the base priority level assigned to 
the task group. 


The physical interrupt level at which a task executes is the sum 
of the following: 


1. The highest level number assigned to a configured device 
plus 4. 


2. The base priority level number of the task group 
3. The relative priority level of the task within that group. 
This sum must not exceed 61. 


Interactive user tasks are usually given higher priorities 
(lower level numbers) than absentee user tasks. Tasks that are 
1/0-bound should be run at a higher priority than tasks that are 
Centra) Processor (CP) bound. This permits 1/0-bound tasks, 
which run in short bursts, to issue 1/0 data transfer orcers as 
needed, wait for 1/0 completion and, while in the wait state, 
relinquish control of the central processor to CP-bound tasks. 
Otherwise, if the CP-bound tasks have a higher priority, the 1/0 
devices would be idle while [/Q-bound tasks waited to receive 
central processor time. (Timeslicing minimizes the ability of 
CP-bound tasks to interfere with interactive and 1/0 bound 
tasks.) 


Logical Resource Numbers 


A Logical Resource Number (LRN) is an internal identifier used 
to refer to task code and devices independently of their 
physical priority levels. Use of LRNs makes Assembly language 
application task code independent of priority levels so that, if 
circumstances require a change in priority levels, the task code 
does not have to be reassembled. 
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Device Logical Resource Numbers 


The system uses DEVICE directives to assign LRN values. Device 
LRNs may have values from 2 through 252, and from 256 through 
4002. LRN O is used for the operator terminal; LRN 1 is usec 
for tne bootstrap device; and LRNs 4003 through 4095 are 
reserved for other system uses. Figure 5-3 is an example of 
LRN assignments for devices and system tasks. 


LRN . Use 


0) Operator terminal 


1 System disk 


2 Reserved 

sc} System disk companion (if any) 

4 User aspect of dual-purpose operator terminal 
5 Other aevices 


a rere 


Figure 5-3, Example of LRN Assignments for 
System Tasks and Devices 


Application Task Logical Resource Numbers 


Assigning 
LRNS 


wn 


-14 


LRN assignments to application program tasks within each task 
group are not dependent on the system configuration on which the 
application task group is running. You can assign LRNs or have 
the system select the highest numbered LRN available at task 
creation. 


LRNs are assigned to task code within an Assembly language 
application program through specification of the Create Group 
and Create Task macrocalls as wel’ as the macrocalls that build 
data structures ($10RB, $TRB, and so forth). LRNSs can be 
assigned at the contro] language level through the commands for 
the creation of task groups and tasks. 
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LRN Values 


Non-LRN 
Tasks 


An LRN for an application task can have any value from 0 through 
4095. Within a task group, the LRN for each task must be 
unique. More than one LRN can be associated with the same 
priority level (for example, two tasks at level 23 can have LRNs 
of 28 and 29, respectively). 


Two kinds of tasks do not have LRNs: 


e The lead task of any task group 
e Any spawned task. 


Logical File Numbers 


Assigning 
LFNs 


LFN Values 


Logical file numbers (LFNs) are internal file identifiers 
associated with file pathnames at the source language program 
level or at command level. LFNs can be used to reduce program 
dependence on actual file pathnames (which are likely to vary). 


LFNs can be associated with file pathnames in Assembly language 
or COBOL programs, or through Create File, Get File, and 
Associate commands. 


An LFN can have any value from 0 through 4095. 


Task and Resource Coordination 


Task Requests 
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Tasks can be coordinated in either of two ways: 


@ Through the use of tasking requests 
@ Through the use of semaphores. 


One task can request another to execute asynchronously with it, 
or the requesting task can later wait for the completion of the 
requested task. Both tasks have access to the request’ block 
provided by the requesting task, and can use it to pass 
arguments between them. 


Task Execution 


Semaphores 


Resource 
Ceardination 


Semaphore 
Macrocalls 


Semaphores support an application-cesigned agreement among tasks 
to coordinate tne use of a resource such as task code or 2 
file. A semaphore is defined by a task within a task group and 
js available only to the tasks within that group. Use of 
semaphores in an application is essential if the application has 
multiple tasks anc is sharing data in memory. 


For each resource to be controjled, you define a semaphore and 
give it a 2-character (ASCII) name. The semaphore name is a 
system symbol recognized by the system control software; it is 
not a program symbo] that needs Linker resolution. 


In controlling resources, the agreement is that eacn requestor 
of @ resource whose use must be coordinated issues appropriate 
system service macrocalis to the named semaphore to request or 
release the resource. The task that defines the semaphore 
assigns the semaphore's initial value. The system control 
software maintains the current value of the semaphore so as to 
coordinate requesters of the resource Deing controlled. A 
requester obtains use of a resource if the semaphore value is 
greater than zero at the time of the request. If the value is 
zero or negative. the requester is either suspended (waiting for 
the resource) or netified that no resource is availaole, 
depending on how the request was made. 


System service macrocalls are used to: 
o@ Define a semaphore and give an initial value ($DFSM). 


Reserve a semaphore-contro]led resource (SRSVSM). This 
macrocall subtracts a resource or queues a waiter for the 
resource (that is. it decrements the current-vaiue 
counter). $RSVSM suspends the requesting task until the 
resource is ready. 


° 


© Release a semaphore-controlied resource ($RLSM). This 
macrocail adds a resource or activates the first waiter on 
the semapnore queue (that is, it increments the 
current-value counter). : 


e@ Request the reservation of a semaphore-controlied resource 
($RQSM). This macrocall queues a request block (SRB) if the 
resource is not available (that is, it decrements the 
current-value counter). The requesting task must test the 
queued SRB subsequent to the request in order to determine 
when the resource 1s granted. The requesting task continues 
executing unti) it executes 2 SRSVSM macrocall; then it 
waits. 


@ Delete a semaphore ($DLSM). 
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Example A semaphore is a gating mechanism. The initial value you give 
to it depends on the type-of control you want to exercise. For 
example, assume that you want to restrict access to a particular 
resource to one user at a time. The mechanism would work in the 
following way: 


1. Task A defines a semaphore by issuing the macrocall: 
$DFSM 22 


Omission of the value argument causes the initial value to 
be set at Ll. 


2. Task B now issues a $RSVSM macrocall. The counter is 
decremented to 0. Task B gets the resource for itself, 
knowing that no other task using the semaphore mechanism is 
now using or can obtain the resource. 


3. Task C issues a $RSVSM macrocall. The counter is 
decremented to -1. Task C is suspended and put on the 
semaphore queue in first-in/ first-out order (because Task B 
is still using the resource). 


4, Task 8 issues a-$RLSM macrocall when it finishes with the 
resource. The counter is incremented to 0. Task C now gets 
the resource. After Task C issues the $RLSM macrocall, the 


value again becomes 1. 


Use of resources by more than one user at a time can be arranged 
by adjusting the initial value of the semaphore. For example, 
an initial value of 2 allows two users, a value of 4 allows four 
users, and so on. The value chosen as the initial value cf the 
semaphore depends on the nature of the resource and its intended 
use. 


If it is undesirable for a task to be suspended while a resource 
is in use, the $RQSM macrocal! can be used instead of $RSVSM to 
reserve a resource. $RQSM is an asynchronous reservation 
request ($RSVSM is a synchronous request) that causes a request 
block to be queued for the resource so that the issuing task can 
do cther processing before the needed resource is available. 
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TASK HANDLING 


Task Priority 


Device 
Drivers 


More than one task can be concurrently active. Ina 
multiprogramming environment, a task in each of several task 
groups can pe active ana compete for system resources. Another 
possibility is a multitasking application where several tasks 
executing under one task group can be active to compete for 
system resources among themselves and with tasks from other task 
groups. 


A FORTRAN or Assembly language program can include requests to 
activate several tasks anc synchronize their execution; these 
requested tasks can execute concurrently. A COBOL, BASIC, C, 
Pascal, or Ada program executes as a single task, but can 
include commands to activate otner tasks. 


Levels 


For the system to sequence the execution of tasks, each task 
must be assigned a priority level. In monoprocessor systems, 
task competition for the central processor resource is governed 
by the hardware/firmware linear priority scan of level activity 
indicators. Tasks on the same priority level execute serially 
in the order in which they are requested. In multiprocessor 
systems, tasks are ordered in a software queue according to 
their priority levels. The task at the top of the queue js 
dispatched when a protessor becomes free. When it is assigned 
to a processor, the task executes at the same priority level as 
it would on a monoprocessor system. 


The highest priority active task receives all available central 
processor time until it waits, exceeds the timeslice value, 
terminates, or is suspended. In both monoprocessor and 
multiprocessor systems, the task can be interrupted by a higher 
priority task. 


It should be noted that all device drivers are considered to be 
tasks in the above sense. Using the File System, buffered 
device drivers can execute concurrently with tasks. Orivers 
execute on the central processor priority levels assigned to 
individual devices and thus have their own contexts. The device 
drivers provided in the system are written in reentrant code, 
are capable of servicing multiple devices, and execute on any 
central processor in a multiprocessor system. 


CZ03-02 


Task Execution 


Task Activation 


A user task becomes active when a Spawn Task or Enter Task 
Request command is issued for it. The Spawn Task command can 
request that the invocation of the task be delayed until a 
specified time interval has elapsed. FORTRAN programs can cause 
a task to become active through the START and TRNON statements. 
Assembly language programs can issue a $RQTSK OR $SPTSK 
macrocall to activate a user task. Any application program can 
issue a command to spawn or request a task by calling the ZXEXCL 
run-time routine. 


When you want more than one task to execute concurrently, you 
Must specify each task in a Create Task or Spawn Task command 
(or system service macrocall). 


The procedural code for a requested task is either in a unique 
bound unit or in-a bound unit shared with a task that was 
previously created. When a task is requestec, the system 
searches for its identifying LRN in the table of LRNs associated 
with the task group under which the task is executing.. The 
system activates the task, if it is not already active. 


Task Termination 


To terminate, tasks of Assembly language programs must contain a 
Request to Terminate ($TRMRQ) macrocall. Compilers provide this 
call in the object text. $TRMRO is executed after the task 
completes execution. 
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TASK STATES 


Dormant 


Active 


Wait 


Suspend 


Tasks can exist in any of the logical states cescribed below. 


A task is in tne dormant state when there ‘s no current request 
for it. A task enters the dormant state if it is createc but 
never requested, or when a terminate request is issued against 
it. A task remains dormant until a request is placed against it 
or it is deleted. If deleted, it is erased, memory is reused, 
and the task cannot be reactivated. 


A task is in the active state when it is executing or.when it is 
ready to execute if its priority level becomes the highest 
active level in a central processor. A task remains active 
until it waits, terminates, or is suspended. Tasks in the 
general ready queue are active. 


A task is in the wait state when it is not executing. It may 
have caused its own execution to be interrupted until (1) the 
completion of an event such as the completion of a requested 
task, or (2) a timer request is satisfied, or (3) a task 
releases a semaphore. A waiting task loses its position in the 
priority level round-robin queue. 


An 1/0 order to disk, magnetic tape, the operator terminal, or 
an unbuffered card reader usually results in a wait condition. 
Task code written in FORTRAN or Assembly language will also wait 
in the following circumstances: {1) a write order is issued to 
an interactive terminal or to a printer when a previous write 
has not completed, (2) a read order is issued before the 
transfer of the current message from an interactive terminal is 
complete (the RETURN key is not pressed). In COBOL, these 
circumstances result in a wait if the program is executing its 
1/0 statements in synchronous mode; otherwise, if in 
asynchronous mode, a status code value of 9] is returned with no 
waiting. 


A task is in the suspend state when it is removed from execution 
by an external human action (for example, the operator entering 
@ Suspend Group command or a user interrupting a program with a 
Break action). The task s activated through another human 
action (for example, the operator enters an Activate Group 
command or a user enters a command after the Break action). 
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INTERTASK AND INTRATASK GROUP COMMUNICATION 


Information can be passed among task groups and tasks by means 
of request blocks, common files, and the message facility. 


Request Blocks 


Common Files 


Pipes 


Task code written in Assembly language can pass information to 
other Assembly language tasks in the same task group by using 
variable-length request blocks. The request blocks can contain 
data or pointers to information structures. All request blocks 
must be in common address space so that they can be shared by 
the tasks. (Refer to the System Programmer's Guide for details 
on building request blocks.) Higher level languages cannot use 
request blocks directly; they require called subroutines written 
in Assembly language. 


Tasks within the same task group and tasks within different task 
groups can communicate through disk files. The concurrency 
status must be the same for all tasks using the files. The 
requesting tasks must have access rights to the files. 


A pipe is a Special type of sequential file that also provides 
synchronization and queuing facilities to cooperating tasks. 
Pipes are used by tasks in different task groups (applications) 
er in the same task group, to communicate with each other. 
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Message Facil 


y 


The message facility allows two or more task groups (users) or 
two or more tasks within a task group to communicate with one 
another. This communication is accomplished through containers 
called maiiboxes. Messages (requests) sent to a task or task 
group are queued in a majibox and are dequeued when received. 


To control the sending and receiving of messages, the message 
facility proviaes a number of macrocalls and commands. One set 
of macrocalls (Initiate, Senc, and Terminate Message Group) 
allows a message (a request) to be sent to a mailbox; another 
set of macrocalls (Accept, Receive, and Terminate Message Group) 
allows a message to be received from a mailoox. Commands are 
provided to allow you to senc, receive, list, and cancel 
messages (requests). The Mail command is provided to allow you 
to send messages (mail) to another user's mailbox anc to display 
mail in your own mailbox. 


Deferred processing of print and task group requests is carried 
Out through the use of the message facility. Deferred 
processing is described later in this section. 


Before the message facility commands or macrocalls can be used, 
and before the deferred processing of print anc task group 
requests can be initiated, you (or the operator) must create the 
mailboxes and activate the message facility task. 


The paragraphs below describe mailbox creation, the activation 
of the message facility task, and the command anc macrocal) 
interfaces. 
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Creating Mailboxes 


Setting 
Access 
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Three steps are involved in the construction of mailboxes. You 
must (1) create the mailbox root directory, (2) create the 
mailboxes, and (3) set access controls on the created 
mailboxes. (Refer to the Commands manual for details.) 


The mailbox root directory is the directory that is to contain 
the simple names of the mailboxes. 


The system assumes that the mailbox root directory is in the 
>MDD directory. (An MDD directory is supplied on the system 
root volume.) You, however, are free to create your own mailbox 
root directory through the Create Directory command. 


Each mailbox is created through the Create Mailbox command. 
This command creates a directory corresponding to the mailbox 
name and a file ($MBX) within that directory defining the 
mailbox attributes. 


To prevent unauthorized use of the message queues, you should 
set access controls as follows: 


e Senders must be given 11st access on the directory defining 
the mailbox. 


e Receivers must be given read access on the $MBX file for a 
given mailbox. 


Individual mailboxes can be deleted using Delete Mailbox 
commands . 


iting Message Facility Task 


The Start Mail operator command activates the message facility. 
This command contains an optional argument used to set the name 
of the mailbox root directory to other than the default 
directory pathname (>MDD). 
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Message Facility 


Mail Command 


SMM and AMM 
Commands 


Command Interface 


The commands that can be used to send/receive messages (mail) 
are Ma‘l (MAIL), Send Message Mailbox (SMM), and Accept Message 
Mailbox (AMM). Commands are also provided to list and delete 
messages. 


The Mail command (aiso referred to as the local mail facility) 
is used to send and receive multiline messages to/from the 
mailbox whose name (id) is tne same as the person ic of the 
receiving user. A message sent by a Mai] command is queued in 
the mailpox and displayed only if the receiving user issues a 
Mail command. 


To send a mail message, you issue the Mail command, specifying 
the mailbox id (person id) of tne user to receive the message. 
The message to be sent can be Iccated in a file (named by an 
argument of the command) or it can be entered after the Mail 
command has been invoked. 


To receive mail messages, you issue the Mail command without 
arguments. The contents of your mailbox are displayed when the 
command is executed. If you request deletion of the messages, 
they are deletec from the mailbox after being asplayeds 
Otherwise, the messages remain in the mailbox. 


The Send Message Mailoox (SMM) and Accept Message Mailbox (AMM) 
commands (also referred to as the local message facility) are 
used for single-line messages that must oe viewed immediately or 
at a specified time. The AMM command is used to specify that 
messages sent Dy the SMM command be displayed when received or 
at the time specified in the SMM command. 


To send a message, you issue the SMM command, specifying the 
person id (mailbox) to which the message is to be sent. You 
inciuce the message in the command line. You can include the 
-TIME argument to specify a delivery time for the message. You 
Can send a broadcast message by specifying * in place of the 
mailbox in the SMM command. The message will be sent to all 
jogged-on users who have issued an AMM command indicating their 
willingness to accept messages. ° 


Te receive messages, you issue the AMM command. Messages 
already in your mailbox are displayed. Subsequent messages are 
displayed when placed in your mailbox. Messages whose date and 
time for display have not been reached are not displayed. 
Messages are deleted from your mailbox as scon as they are 
displayed. 
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Senders can use both the Mail and SMM commands. A receiving 
user who issues a Mai] command receives both types of messages. 
If you issue an AMM command, you receive only messages sent by 
the SMM command, unless you specified the -IMBX * argument. 
Only when this argument is specified wil] you receive both types 
of messages via the AMM command. 


The -IMBX argument also allows you to specify by name 

(person id) the sending user from whom you will accept messages 
for immediate display. Messages sent by other senders are 
stored in your mailbox. The -AMBX argument allows you to obtain 
messages from mailboxes other than the one associated with your 
person id. 


Message Facility Macrocall Interface 


Send Message 


You can use the message facility on the Assembly language Jevel 
by using the macrocall interface. To permit the sending and 
receiving of messages, the message facility provides the 
following macrocalls: 


@ Initiate Message Group ($MINIT) 
e@ Send ($MSEND) 

@ Accept Message Group ($MACPT) 
@ Receive (SMRECV) 

e Terminate Message Group ($MTMG) 
@ Count Message Group ($MCMG) 

@ Cancel Enclosure Level ($MCME). 


The information associated with these macrocalls can be passed 
by means of request blocks. 


A task group that wishes to send a message to a mailbox must 
issue a $MINIT macrocall to open the send-message session. The 
mailbox is identified by a name entered in the request block. 

AS a resuit of this macrocal], the message facility returns a 
message id, unique to the task group, to identify the message to 
the other macrocalis (that is, the send). 


The task group then issues one or more $MSEND macrocalls to send 
message data. The send-message session is closed by the $MTMG 
macrocall or, alternatively, by the $MSEND macrocall. The 
sending task group can issue the SMCME macrocall to delete the 
last record of an incomplete quarantine unit or the entire 
incomplete quarantine unit. (A quarantine unit is the smallest 
amount of transmitted data available to a receiving task 
group.) Receipt of the message can be deferred by the sender. 
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Receive 
Message 


Effective 
Use 


A task group wishing to receive a message from a mailbox issues 
a SMACPT macracal] to open the receive-message session. The 
mailbox is identified as described above for the SMINIT 
macrocall, and the message facility returns a message id to be 
used by the SMRECV and $MTMG macrocalls. 


The task group then issues one or more $MRECV macrocalls to 
receive message data. The receive-message session must be 
closed with a SMTMG macrocall. 


The message may be accepted on the following selection criteria: 


e First available message 
Sequence number 
@ Suomitter name 
@ Suomitter name and sequence number. 


The receiving task group can request the message in record sizes 
other than those in which the message was sent. The receiving 
task group delimits the amount of received data by range or 
enclosure level. 


The message facility can be used most effectively by two task 
groups wishing to communicate if they both simultaneously send 
and receive a message. To accomplish this, each of the task 
groups shoulc issue the $MINIT macrocall to open the send- 
message session and the $MACPT macrocall to open the receive- 
message session. In this case, the quarantine unit is the 
vehicle used to exchange data between the two task groups. 


DEFERRED PROCESSING FACILITIES 


The system's deferred processing facilities are supported by the 
message facility (refer to "Message Facility" above). In 
deferred processing, the messages are requests. 


Deferring the execution of interactive and absentee task group 
requests makes it possible for you to gain greater control over 
the processing sequence. Deferring print requests allows you to 
obtain program independence from the availability of print 
devices. Queuing and later transcribing reports provides a 
spocling capability that places printing and punching outside of 
program context. 
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‘Deferring Task Group Requests 


When placing an interactive or absentee task group request, you 
can have the request entered in a disk queue and can postpone 
any action being taken on the request until a specified time. 
When the request queue structures are on disk, memory space is 
conserved and the data in the queues can be recovered in the 
event of a system failure (refer to Section 6). 


Assuming that an interactive and/or absentee task group has been 
created, two steps are required to defer group requests. The 
operator must create the request queues (mailboxes), and you 
must issue task group requests with optional arguments 
specifying the time each request is to be activated. 


Creating Task Group Request Queues 


The operator uses the Create Group Request Queue command to 
create queue structures in which requests issued to a given task 
group will be stored. The operator must also issue a Start Mail 
command if one had not been previously issued. 


Queuing Task Group Requests 


You queue task group requests by issuing an Enter Group Request 
command. You can postpone action being taken on a request by 
specifying the -DFR (defer for interval) or -TIME (defer until 
date/time) arguments. 


Once the operator has issued a Create Group Request Queue 
command for @ task group, all further requests for that group 
are queued whether or not the requests are being deferred. 


If the operator does not issue a Create Group Request Queue 
command, you can still submit group requests but will not be 
able to defer the requests. 
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Deferring Print Requests 


The system provides a deferred printing capability under which 
your requests for printing specified files are queued in memory 
or disk mailpoxes. The actual transcription of the files is 
done at a later time, uncer the control of an operator-created 
system task group called a daemon. 


After you submit a deferred print request, you can resume normal 
activities, log off, or reboot the system without losing the 
request. 


The three steps involved in deferred print processing are (1) 
creating the mailboxes, (2) activating the daemon, and (3) 
queuing the print requests. The information in the following 
paragraphs is conceptual. Detailed procedures for deferred 
orinting are given in the System User's Guide. 


Creating Print Request Mailboxes 


The operator establishes the mailboxes that are to contain the 
queued print requests. The mailboxes can be im memory or on 
disk. The mailbox names must be in the form SPR.Qn (n is an 
integer from 1 through 9 that identifies tne relative priority 
of the queue, with 1 being the highest priority and 9 the 
lowest). . 


Creating the Print Daemon 


The operator is responsible for defining and activating the 
daemon to process the print requests. 


To create a daemon task group, the operator issues a Start Mail 
command (if one was not already issued), a Create Group command 
naming the daemon to be created, anc an Enter Group Request 
command identifying the mailboxes to be used for queuing the 
requests and the devices to be used for printing. 


Multiple daemon task groups can be run concurrently, using 
common or separate sets of mailboxes and printers. 


Queuing Print Requests 


Once the daemon task group is active, you can queue, print, or 
punch requests by issuing Deferred Print commands. You can 
employ the -TIME argument to defer the printing of a file until 
a specified date and time. 
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Queuing and Transcribing Reports 


Any file in print or punch format (i.e., any report file) can be 
queued and subsequently transcribed to an available printer or 
card punch. Report queuing and transcription is a spooling 
Capability that provides automatic and manual report 
transcription, time-of-day printing or punching, and an 
automatic setup function that includes a sample transcription 
file (template). 


The report queuing and transcription facilities contro] report 
transcription outside the context of the program. Reporting 
procedures for identical software can be totally different in 
different situations without requiring reprogramming. 


Report queuing and transcription have three major aspects: 
creating a report queue, queuing a transcription request, and 
transcribing a report. 


Creating Report Queues 


Report Queue 
Profile 


A report queue is a directory that allows you to place a report 
transcription request in a queue and subsequently transcribe the 
report. Report queues are created, modified, and deleted 
through Report Queue Maintenance (RQM) commands. The 
characteristics of the report queues are determined when the 
Queue is created; the contents are determined when a report 
transcription request is placed in the queue. 


When the report queue is created. a report queue profile file is-- 
built. The report queue profile file designates the 
characteristics of reports whose transcription requests will be 
entered in the report queue. The report characteristics 

include: 


Name of form descriptor 

Format of reports to be queued (print or punch) 
Transcription mode (automatic or manual) 

Column number at which printing is to begin 

Line at which printing is to begin (head of form) 
Number of print lines per inch 

Number of copies of report 

Time at which report is to be transcribed 
Heading line 

Destination line. 


The report queue profile file is complete when the report queue 
jS created; however, various aspects of the profile can be 
overridden when the report transcription request is queued. 
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Queuing Report Requests 


The name of a report to be supsequently printed or punched is 
placed in a report queue through the Queue Report (QRPT) 
command. This command also associates with the report 4 
specialized report queue profile file that governs the details 
of the report transcription. Once a request has beer queued. it 
remains queued until the file has been transcribed or the 
request pathname has been deleted through a report queue 
maintenance renew or delete function. 


Transcribing Reports 


Automatic 
Mode 
Manual Mode 


Previousiy queued reports are written to a printer or card punch 
through the Unspool {UNSP) command. A single UNSP command can 
unspool all current and future requests. The printing or 
punching characteristics are determined by the report queue 
profile file created through the ROM command, the specialized 
report queue profile file created by the ORPT command, the 
user's activities, and the arguments specified in the UNSP 
comand. 


The UNSP command defines the report queue and the hard copy 
device to be used. After the command is executed, the 
specialized report file (if any) is deleted from the report 
queue. All reports whose profile matches the specified profile 
are unspooled in a Single invocation of UNS. 


The report queue profile fite can specify tnat the reoort is to 
be transcribed automatically or manually. 


Automatic transcription is used when constant monitoring of a 
report queue is desirec. When there is no transcription 
activity in progress, the unspool routine suspends itself for 
l-minute intervals. When transcription of the queue is 
activated, each report in the queue is printed immediately 
untess one of the following is true: 


e@ Manual mode was specified in the controlling profile. 


e@ Tne specified time of day for report transcription has not 
been reached (or exceeded). 


Manual mode is used to transcribe reports in a nonautomated 
fashion. When you require the reports, you issue the UNSP 
command. Ail reports on the queue are transcribed immediately, 
regardless of time or mode. When the queue is empty, UNSP 
terminates. 


€203-02 


